home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9804 / 000119_9606585c@udcf.gla.ac.uk _Tue Apr 21 10:04:25 1998.msg < prev    next >
Internet Message Format  |  1998-05-13  |  5KB
  1. Return-Path: <9606585c@udcf.gla.ac.uk>
  2. Received: from lenzie.cent.gla.ac.uk (lenzie.cent.gla.ac.uk [130.209.30.11])
  3.     by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id KAA22884
  4.     for <willy@odie.barnet.ac.uk>; Tue, 21 Apr 1998 10:04:23 +0100
  5. Received: from localhost (9606585c@localhost)
  6.     by lenzie.cent.gla.ac.uk (8.8.4/8.8.8) with SMTP id KAA16097;
  7.     Tue, 21 Apr 1998 10:04:37 +0100 (BST)
  8. Date: Tue, 21 Apr 1998 10:04:34 +0100 (BST)
  9. From: James Craig <9606585c@udcf.gla.ac.uk>
  10. X-Sender: 9606585c@lenzie.cent.gla.ac.uk
  11. To: Matthew Wilcox <willy@odie.barnet.ac.uk>
  12. cc: linux-arm@vger.rutgers.edu
  13. Subject: Re: Installing on an 4 MB A5000
  14. In-Reply-To: <199804210330.EAA21711@odie.barnet.ac.uk>
  15. Message-ID: <Pine.GSO.3.95.980421095758.7028E-100000@lenzie.cent.gla.ac.uk>
  16. MIME-Version: 1.0
  17. Content-Type: TEXT/PLAIN; charset=US-ASCII
  18. Status: RO
  19.  
  20. On Tue, 21 Apr 1998, Matthew Wilcox wrote:
  21.  
  22. > Russell King - ARM Linux Admin
  23. > > 
  24. > > Hi.
  25. > > 
  26. > > Maybe I ought to make my position quite clear on this subject:
  27. > > 
  28. > > 1) I believe that RedHat offers the best compromise for ARM Linux.
  29. > 
  30. > That's your belief and you're entitled to hold it.  Since you created the
  31. > distribution, others should accept that.  I still like the idea of creating
  32. > a Debian distribution, but I think that time spent working on that would
  33. > be wasted before we have libc 6.
  34. Possibly, although I'm not sure. I can't think of any reason why slackware
  35. or Red Hat should be any different in that respect. :) 
  36. > > 2) The RedHat installer cannot be used on floppy to install on machines
  37. > >    with 4MB of ram.  With a future PartMan, it will be possible to copy
  38. > >    a small partition image into the drive, thus allowing non-floppy
  39. > >    based installation.
  40. > 
  41. > That will be really sexy.
  42. Yep, very nice idea. That would solve a *lot* of problems with the setup.
  43. > > 4) The 2.1.xx kernels currently are going to require a lot of changes
  44. > >    to get them to run properly on the older architectures:
  45. > >    a) The MEMC is quite unlike any other memory manager in the world,
  46. > >       and doesn't fit any sensible memory management model that Linux
  47. > >       could provide.  Therefore, the MM is less than optimal.
  48. > 
  49. > You can say that again!
  50. Yep. :)
  51. > >    b) With the advent of ELF, and it's requirement to map the same
  52. > >       data in two logical locations, this will require more
  53. > >       modifications to the kernel.
  54. > 
  55. > I *thought* it had been agreed that that wasn't actually necessary, it was
  56. > merely the way the x86 decided to do it?
  57. Likewise, but hey, I don't understand ELF all that well anyway. :)
  58. > >    c) The large page size requires numerous modifications to the
  59. > >       way memory is allocated in several parts of Linux.
  60. > 
  61. > Yes, I noticed that in the patches.  Are there not also issues on Alpha's
  62. > with their 8k page sizes?  I guess they tend to have so much more memory
  63. > that this is a moot point.
  64. Truly.
  65. > >    d) The kernel's malloc() routines need a hack to reduce the
  66. > >       inherent overheads that it produces on large page machines.
  67. > >    I'm not saying that it'll be impossible to do, but more that
  68. > >    I'm beginning to wonder if the old machines are really worth the
  69. > >    effort, and whether we're going to be able to continue integrating
  70. > >    the architecture-specifics for these machines with obsolete
  71. > >    processors into Linus' kernel source tree.
  72. Leaving support for large page sizes in the kernel would be a good move,
  73. since it increases the range of different CPUs that linux *could* be
  74. ported to with relatively little work.
  75. > > 5) It is my intention to continue integrating the sources as is or as
  76. > >    patches allow for these old machines.  I shall be working on this
  77. > >    area, but since my resources are required for other purposes, this
  78. > >    will not happen with any great speed.  If someone wishes to take
  79. > >    over the kernel admin/hacking for the A5000, they are welcome.  If
  80. > >    you want to know more details about this, then please mail me.
  81. I'm in no position to help at present, sadly. :(
  82. > IMO, it would make more sense to separate out the port into an arm26 and
  83. > an arm32.  Yeah, I know this is a really bad time to mention it :-) Of
  84. > course, there's nothing to stop arm32 machines executing arm26 binaries.
  85. > This might encourage someone to take responsibility for the arm26 tree
  86. > off your hands.
  87. Interesting idea, but I suspect that it would lead to a complete halt on
  88. progress on the arm26 architecture. At least with the two together, we
  89. still get progress - if arm26 and arm32 were seperate, we'd have to update
  90. the arm26 code seperately from the arm32 stuff, even if the changes were
  91. applicable to both architectures.
  92.  
  93. --
  94. James Craig <jcraig@mad.scientist.com>
  95.             <9606585c@udcf.gla.ac.uk>
  96.